The present invention relates to a performance measuring system and method which provides a framework for the measurement of data transfer between processes, and to a system and method for measuring and comparing transaction times for the transfer of data between various processes running on nodes of e.g. a distributed system using different data transport mechanisms.
The transfer of data between processes (for example between a server and a client) can be achieved by various transport mechanisms (for example UNIX message queues, Sockets, JMS, CORBA and the like).
The actual time taken for the data transfer to take place will be an important factor in deciding the mode of transport to use.
Determining the time taken for such data transfers has generally been a laborious process, in which a tester would need to write a number of programs specific to each machine and data transfer mechanism, and would have to run the programs from each machine, and then collate and compare the results.
An object of the present invention is to provide a framework which can be used for the purposes of measuring and thereby comparing data transfer speeds and the like between processes running on the nodes of a computer network for different transport mechanisms.
Viewed from one aspect, the present invention provides a system for testing data transfer between a plurality of processes run on one or more nodes of a computer network, the system including a central manager component, and an agent component associated with each of the nodes, wherein the manager component instructs the agent components to conduct data transfer tests, and wherein the manager component receives the results of the tests from the agent components.
The use of a manager component, separate from a number of agent components running on the nodes, provides a number of advantages in testing.
It allows for a centralised control of the testing, with the location of the manager component independent of where the benchmarking takes place. It also allows the reporting of the results by the manager component to be independent of the various measurement techniques employed by the agent components.
It can further provide a system which is extensible and is adaptable to the testing of new transport mechanisms. It is simple to use, as the user need only interface with the manager component and a set interface structure, no matter the types of transport mechanism under test.
As the transfer mechanisms involved in the tests are abstracted in the framework provided by the system, a user need not concern themselves as to the actual implementation of the data transfers, etc., and can focus on the tests required and can analyse the results centrally through the manager component.
Preferably, the manager component is remote from the nodes and runs on a separate machine, so as not to interfere with the load put on the nodes under test.
Preferably, the manager component passes parameters to the agent components, and the agent components create and initialise processes for carrying out the required data transfers. The data transfer may be carried out between pairs of processes, e.g. between a client process and a server process.
The parameters passed from the manager component to the agents may indicate a role for the processes which an agent component is to create, e.g. a client or server role, and may indicate the type of transfer mechanism to use, e.g. Sockets. They may also include parameters specific to the communication type to be employed, e.g. a hostname and port number, and parameters specific to the measurement, e.g. the number of loops to make and/or the message length.
An agent component may verify these parameters (e.g. to check that a port specified by the manager component is free), and may then create and initialise the necessary processes for carrying out a test. The manager component may also synchronise the starting of the tests between the various processes. For example, the processes at an agent may block on an object, such as a single mutex. The agents may then be notified by the manager component as to when management is to be started, and will accordingly update the mutex so that the processes will start to exchange messages.
Once the processes have exchanged data, the agent components can determine the benchmarking results. The agent components may then send the results back to the manager component automatically, or the manager component may poll the agent components for the results.
On receiving the results of the tests from the agent components, the manager component may calculate metrics for the data transfer mechanisms (e.g. the total bytes exchanged per second), which may then be displayed or otherwise communicated to the user.
The manager component may also instruct agent components to abort a test, if this should be required for any reason, e.g. in order to execute the test at a later time or because an error has been detected.
The transport mechanisms which may be tested may include various messaging middleware, and may include transport mechanisms such as UNIX messaging queues, Sockets, RPCs (Remote Procedure Calls), CORBA (Common Object Request Broker Architecture), and JMS (Java Messaging Service).
The manager and agent components may be implemented in any suitable form, depending on the machines and languages used, as would be well understood by a man skilled in the art in the light of the present teachings.
The processes created by the agents will depend on the messaging types and the agents. For example, if the messaging type is Sockets, and the agent is JAVA based, then the processes may be JAVA threads.
The tests may be between processes running on different nodes (hereinafter referred to as xe2x80x9cInter-modexe2x80x9d tests) or may be between processes running on the same node (hereinafter referred to as xe2x80x9cIntra-modexe2x80x9d tests). They may also be carried out using a mixture of both Inter and Intra-mode tests. By having the manager component removed from the testing procedure, a user of the system can use the same interface (through the manager component) for both Inter- and Intra-mode testing.
The Inter-mode and Intra-mode testing is made possible with the same interface because of the separation of the benchmarking interface from implementation. For each communication type the benchmarking interface is implemented and made accessible at all the agents. This way the framework is extensible for other communication types also.
The manager component may communicate with the agent components in any suitable manner, and, in one embodiment, communication may take place using CORBA. Thus, the agent components may register with the CORBA naming service using unique names that are also known to the manager component, and the manager component will use these names to locate the agent components through the CORBA naming service. The use of CORBA allows the agent components to be placed on nodes anywhere on the network.
Preferably, the manager component includes a repository for storing scripts of test parameters and the like. This allows for the re-running of tests, and the automated reproduction of results.
The manager component may have a user interface which enables a user to select the mechanism of transfer to be tested, the mode of the transfer (i.e. Inter or Intra-mode), the number of sets of processes, and the number of data transfers.
The present invention also extends to methods of testing data transfer between processes running on one or more nodes of a network in accordance with the above features, and to software and hardware for implementing the same.